A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office, patent file or records, but otherwise reserves all copyrights whatsoever.
1. Field of the Invention
The invention relates to the modification of software, and in particular, to the replacement of software in an operating computer system.
2. Description of the Related Art
One aspect of computer software is that it must be periodically updated with revisions, additions and/or deletions in order to continue to provide adequate functionality to the user, to optimize the software and to correct errors and discrepancies that arise throughout the life of the software. As new features are added to software, it is desirable to replace the old software with the new versions as early and as easily as possible in order to provide the user with the features of the new software.
In certain types of computing systems, such as stand-alone or batch processing systems, changing software from one version to another presents few obstacles. Typically, the computer system is merely shut down during a period of the day when there is little activity and maintenance personnel are readily available. The old software is then simply removed and replaced by the newer version of the software. Thereafter, the computing system is restarted and all future data processing is done with the new version of the software. This procedure, of course, assumes that the new software has been adequately tested and debugged on an offline system to the point that the software personnel and the operational management are confident that it will adequately perform the functions for which it is intended without undue interruptions that may require halting and then re-starting the entire computing system.
In other types of computing systems, such as modern stored program control (SPC) telecommunications exchange systems (commonly referred to in the industry simply as "switches"), neither the testing of new versions of software nor the changing of software in the system is as easy as in standalone batch processing systems. For example, new versions of software cannot be effectively tested without being placed into actual operation processing calls. The software must be tested while in operation in order to determine whether the software will adequately function under live operating conditions and whether the new portions will properly interface with all of the other software blocks that form a part of an operational SPC switching system. In addition, telecommunications switching systems are virtually never out of operation. Ideally, these systems would run perpetually, without interruption because of the continuous need for communications services within a community. That is, there is a continuous flow of telecommunications traffic being processed through the system even at off hours of the day or night and any interruption in the operation of the switch results in a disruption of that telecommunications traffic. Such a disruption could be extremely damaging to the system's operation and its effectiveness, as well as to its acceptance among users or customers of the system.
These real-time requirements of telecommunications switching exchanges place severe constraints on both the testing of enhanced versions of the software, or portions thereof, containing new or improved functionality, as well as the substitution of software containing error corrections or "bug fixes" into the switch without disrupting existing telecommunications traffic being processed by the switch. Therefore, integrating new versions of software components or units into the system using the traditional "edit-compile-link-load-run" approach is not desirable. What is preferred is a method that provides the capability to modify or extend the software while the system is in operation, without the need for any downtime.
Attempts have been made to solve the problems associated with incorporating new software into operating computer systems. For example, some advanced on-line operational systems in use today that do not operate in a stand-alone or batch fashion solve the problem of replacing old software in a manner that clearly differs from the method used with stand-alone or batch systems. However, such systems still replace software manually, although more transparently than in stand-alone systems, by requiring that individual users or user groups actively select whether or not to process using the new or revised version of the software. This option may be exercised by users by modifying the concatenation of software to be utilized by processes operating under their individual user-id. The option remains available to users during a fixed period of time, usually measured in weeks or months, in which time the software migrates up several levels in the concatenation structure after successfully operating at each prior level without any discrepancies. Upon reaching the top level of the concatenation, the software is declared "operational" and older versions are no longer available to users of the system. Insertion of new software into the system, as well as its migration up the various levels, is controlled by a process of configuration management--a manual process of reporting, approval, tracking software versions at each level and implementing approved changes.
As with the methods used to update software on batch or stand-alone systems, there are well known drawbacks to incorporating new or modified software into a system in this fashion. It is largely a manual, labor intensive system that is complex and time consuming. It leaves control over whether and in what cases the system will operate with certain new software to the users with no means of performing gradual, restricted, on-line use so that errors do not proliferate or immediately affect all ongoing operations. The method of controlling access to new or revised software is directly linked and limited to the individual user executing the software.
Other attempts to solve at least some of the problems associated with updating software in operational computer systems have taken a different approach. For example, in U.S. Patent No. 5,297,285, issued Mar. 22, 1994, containing an invention by Anders Abrahamsson and Lars Holmqvist and assigned to Telefonaktiebolaget L M Ericsson, there is disclosed a system for dynamically linking software during run-time. That system, however, involves a complex system of indirect addressing that requires use of either a specialized or extended operating system and/or a special compiler. That system also has several drawbacks, including the need for a non-standard operating system. Further, the system will not work with standard applications software. The system is also limited in that it only addresses a portion of the overall problem and does not provide assistance in the areas of gradual testing and changing of control between existing and revised software modules.
In the typical telecommunications system in use today, the problem of changing software or portions of software is even more severe. Although such systems cannot properly be called batch or stand-alone systems, their operation will also be affected whenever a software change is made. The new software is loaded and the data that belonged with the old software is converted and transported to the new software. During the time when this transport is going on, the system cannot register any new calls. This period of disfunction can last as long as an hour or more, making it necessary to schedule software changes for off-peak hours of operation. Even so, an hour of downtime in a telecommunications switching system a very long and costly period because no new calls can be processed during this period and any needs for emergency communications during this time cannot be serviced.
Therefore, it would be highly useful within the telecommunications industry to be able to test and change software during actual operation of the telecommunications switch without disrupting ongoing telecommunications traffic through the system. It would be of further benefit to the telecommunications industry to have the capability to direct a limited and specified portion of traffic through the new software or new portions thereof, so that the software could be tested in an operational environment prior to handling live data. A smooth, transparent method of changing software during operation of the system that requires no special compilers would thus be highly desirable. The system of the present invention provides such a method.